docs: route Peekaboo automation through app host - #22
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0e5a000c03
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| 7. Verify output files with `sips -g pixelWidth -g pixelHeight <path>` or view the image. | ||
| 2. For live UI work, launch `Peekaboo.app`; verify the GUI bridge and its permissions. | ||
| 3. Run `permissions status --json`; if missing TCC, report exact missing grant. | ||
| 4. For screenshots, use `image`; include `--path`, `--json`, and usually `--no-remote` only when deliberately testing caller-local TCC. |
There was a problem hiding this comment.
This newly narrows --no-remote to caller-local TCC tests, but the Common Commands screenshot example above still includes --no-remote, so agents copying the default capture command will bypass the launched app/Bridge path. Peekaboo's Bridge docs state that --no-remote forces local execution, which means normal screenshots will still lose the app-held TCC grants this change is trying to use; please remove it from the default example or label that example as local-TCC-only.
Useful? React with 👍 / 👎.
| [ -x "$PB" ] || PB="$(command -v peekaboo)" | ||
|
|
||
| open -a Peekaboo | ||
| "$PB" bridge status --verbose --json --bridge-socket "$HOME/Library/Application Support/Peekaboo/bridge.sock" |
There was a problem hiding this comment.
In environments where a healthy reusable daemon already exists, this verifies bridge.sock once but does not make the later image/see/click/type commands use that GUI host. The Peekaboo Bridge docs say default automation commands use the daemon first and only --bridge-socket or PEEKABOO_BRIDGE_SOCKET overrides host discovery, so a Mac whose TCC grants are on Peekaboo.app but not the daemon can still fail after following this block; export PEEKABOO_BRIDGE_SOCKET or pass the socket on the live commands.
Useful? React with 👍 / 👎.
1 participant
Summary
Peekaboo.appbefore live UI automation so app-held TCC grants are availablebridge.sockhost from the reusable CLIdaemon.sock--no-remotefor caller-local TCC testsProof
steipete/Peekaboomain atb0184ad3ef88open -a Peekabooplus explicitbridge status --verbose --json --bridge-socket .../Peekaboo/bridge.sockselectedhostKind: guiscripts/validate-skills— 49 skills validated--mode local) — clean, no accepted/actionable findings; fixed the initial default-routing ambiguity it reported